|
|
|
|
|
|
|
Requirements elicitation |
|
Requirements analysis |
|
Rapid prototyping |
|
Human factors |
|
Rapid prototyping as a specification technique |
|
Reusing the rapid prototype |
|
Management implications of the rapid prototyping
model |
|
Experiences with rapid prototyping |
|
|
|
|
Techniques for requirements elicitation and
requirements analysis |
|
Testing during the requirements phase |
|
CASE tools for the requirements phase |
|
Metrics for the requirements phase |
|
Object-oriented requirements? |
|
Air Gourmet case study: Requirements phase |
|
Air Gourmet case study: Rapid prototype |
|
Challenges of the requirements phase |
|
|
|
|
|
Misconception |
|
Must determine what client wants |
|
“I know you believe you understood what you
think I said, but I am not sure you realize that what you heard is not what
I meant!” |
|
Must determine client’s needs |
|
|
|
|
|
Interviewing (primary technique) |
|
Structured versus unstructured interviews |
|
Questionnaires |
|
Forms analysis |
|
Video cameras |
|
Scenarios |
|
Story boards |
|
Trees |
|
Rapid prototyping |
|
|
|
|
Hastily built (“rapid”) |
|
Key functionality |
|
What the client sees |
|
Experimentation and change |
|
Languages for rapid prototyping |
|
|
|
|
|
Client and intended users must interact with the
user interface |
|
Human-computer interface (HCI) |
|
Menu, not command line |
|
“Point and click” |
|
Windows, icons, pull-down menus |
|
Human factors must be taken into account |
|
Lengthy sequence of menus |
|
Expertise level of interface |
|
Uniformity of appearance |
|
Advanced psychology vs. common sense? |
|
Rapid prototype of HCI obligatory |
|
|
|
|
No specification phase |
|
Rapid prototype replaces specification document |
|
|
|
|
|
Specifications: Rapid prototype plus list of
additional features |
|
Advantages |
|
Speed |
|
No ambiguities, omissions, contradictions |
|
Disadvantages |
|
Specification document is contract |
|
Testing requires specifications |
|
Maintenance requires specifications |
|
Conclusion: Do not use rapid prototype as
specifications |
|
|
|
|
Build-and-fix |
|
No specifications, no design |
|
Quality |
|
Maintenance |
|
Real-time constraints |
|
|
|
|
|
Expensive option |
|
Reuse rapid prototype |
|
Cheap option |
|
Discard rapid prototype |
|
|
|
Use of different language |
|
|
|
Can safely retain (parts of) rapid prototype if |
|
Prearranged |
|
Passes SQA inspections |
|
This is not “classical” |
|
|
|
|
|
Consensus |
|
Management Implications |
|
Immediate delivery |
|
Instant maintenance |
|
Waterfall model—get it right first time |
|
Rapid prototyping—many changes, then discard |
|
Increased interaction with clients |
|
|
|
|
|
|
Not proven beyond all doubt |
|
Experiment of Boehm, Gray, and Seewaldt (1984) |
|
Seven different versions of product compared |
|
four specified, three prototyped |
|
Prototyping, specifying yielded equivalent
performance |
|
Prototyped versions had 40% less code, 45% less
effort |
|
Prototyped versions were lower on functionality
and robustness, higher on ease of use and ease of learning |
|
Specifying made integration easier |
|
|
|
|
|
Important facts (not often mentioned) |
|
Experiment on seven teams of graduate students |
|
Three teams of size 2, and four teams of size 3 |
|
Ten week duration |
|
No maintenance |
|
Treat results as indications, not facts |
|
|
|
|
|
Analysis of 34 case studies [Gordon and Bieman,
1992] |
|
29 successes, 2 failures, 3 neutral |
|
(But few failures are published!) |
|
All agreed |
|
User participation was essential, user needs
were met |
|
Not all issues were addressed in all case
studies |
|
(Only 16 mentioned ease of use, but all 16 were
positive) |
|
Choice of prototyping language was not important |
|
|
|
|
|
Discard or retain rapid prototype? |
|
Diametrically different processes used |
|
18 recommended retention, 7 said discard |
|
6 out of 6 large projects recommended retention |
|
|
|
|
Aim: establish client’s real needs |
|
Users must interact thoroughly with rapid
prototype |
|
Issues must reach client |
|
|
|
|
|
|
Language for Rapid Prototyping |
|
Interpreted languages + environments (Lisp,
Smalltalk) |
|
Hypertext (HTML) for user interfaces |
|
4GL |
|
Fewer statements |
|
Often interpreted |
|
Often powerful CASE tools |
|
Danger of 4GL |
|
Part of larger environment |
|
Cheap solution: separate tool |
|
|
|
|
Quality, reliability? |
|
Volatility, convergence |
|
Changes during subsequent phases |
|
Number of times each feature is used |
|
|
|
|
|
On the one hand |
|
The aim is to find the client’s needs |
|
Objects don’t enter into it |
|
On the other hand |
|
Using an object-oriented language for the rapid
prototype may help to identify classes |
|
|
|
|
See pages 308 through 311 of the Fifth Edition
of Object-Oriented and Classical Software Engineering |
|
|
|
|
|
C and Java repid prototypes are available on the
Web at www.mhhe.com/engcs/compsci/schach |
|
For speed in implementation |
|
Data are stored in fixed-size arrays |
|
Only two reports are implemented (the other four
are similar) |
|
Interface is menu driven |
|
|
|
|
|
|
Employees of the client organization feel
threatened by computerization |
|
Requirements team members must be able to
negotiate |
|
The client’s needs may have to be scaled down |
|
Key employees of the client organization may not
have the time for essential in-depth discussions |
|
Flexibility and objectivity are essential |
|
Notes
